home *** CD-ROM | disk | FTP | other *** search
/ MACD 5 / MACD 5.bin / workbench / tools / czesc_3 / run68017 / run68017.readme < prev    next >
Text File  |  1993-01-10  |  16KB  |  365 lines

  1.  
  2. Program name:  Run68017. An upgrade from Run68013
  3.  
  4. Written with:  Profimat (AssemPro) assembler
  5.  
  6. Machine:       Standard Amiga 500 with OS1.3, One floppy drive,1 MByte RAM
  7.  
  8. Author:        Kamran Karimi
  9.  
  10. Source:        Included
  11.  
  12. Run methode:   From both WorkBench and Shell 
  13.  
  14. What it does:  Emulates 30.5 of the 68020 instructions with a 68000
  15.  
  16. By the way:       
  17.  
  18. Program status:This program is semi-shareware meaning that I would like to 
  19. receive money, books or software if you use this program, but it is not
  20. obligatory for poor Amiga users (I am one of them!).
  21. I retain the CopyWrite to to the program including the source and the
  22. executable form of it.
  23.  
  24. Directory contents:
  25.  Run68017 
  26.  Run68017.s 
  27.  Run68017.ReadMe 
  28. ------------------------------------------------------------------------------
  29.  
  30.  CONTENTS:                                         Line #
  31.  Important Notes ---------------------------------  43             
  32.  Emulated Instructions/addressing modes ----------  53
  33.  The Story ---------------------------------------  116
  34.  Program Description -----------------------------  153
  35.  Bugs/Limitations --------------------------------  207
  36.  Compatibility -----------------------------------  248
  37.  Bug Reports -------------------------------------  276
  38.  Next Version ------------------------------------  291
  39.  Finally -----------------------------------------  324
  40.  
  41.  
  42.  
  43. Important Note: 
  44.  As I don't own an Amiga with a  68020 or higher processor, it is only natural 
  45. that not much testing has been done about the correct workings of the program.
  46. My  interpretations  of  the  contents of the books have been my main guide to 
  47. the way the 68020  instructions  and addressing  modes  should  work,and these 
  48. interpretations may be  quite wrong. This means That I  can not  guarantee the
  49. correct  workings  of  the program. It also  means that I should  rely a great 
  50. deal on fellow Amiga users to send me bug reports.
  51. ------------------------------------------------------------------------------
  52.  
  53. Emulated Instructions/addressing modes:
  54.  
  55. The new 68020 addressing modes emulated by this program are
  56.  
  57.  1)  (bd,An,Xn.size*Scale)
  58.  2)  ([bd,An],Xn.size*Scale,od)
  59.  3)  ([bd,An,Xn.size*Scale],od)
  60.  4)  (bd,PC,Xn.size*Scale)
  61.  5)  ([bd,PC],Xn.size*Scale,od)
  62.  6)  ([bd,PC,Xn.size*Scale],od)
  63.  
  64. bd=Base Displacement  ,An=an address register ,Xn=Index register 
  65. od=Outer Displacement ,PC=Program Counter
  66. ------------------------------------------------------------------------------
  67.  
  68.  
  69. The 68020 instructions that are recognized by the program are
  70.  
  71.  1)  Bcc.l   <label> (!)
  72.  2)  BFCHG   <ea>{offset:width}
  73.  3)  BFCLR   <ea>{offset:width}
  74.  4)  BFEXTS  <ea>{offset:width},Dn
  75.  5)  BFEXTU  <ea>{offset:width},Dn
  76.  6)  BFFFO   <ea>{offset:width},Dn
  77.  7)  BFINS   Dn,<ea>{offset:width}
  78.  8)  BFSET   <ea>{offset:width}
  79.  9)  BFTST   <ea>{offset:width}
  80.  10) BRA.L   <label>
  81.  11) BSR.L   <label>
  82.  12) CAS.x   Dc,Du,<ea>
  83.  13) CAS2.x  Dc1:dc2,Du1,Du2,(Rn1):(Rn2)
  84.  14) CHK.L   <ea>,Dn
  85.  15) CHK2.x  <ea>,Rn
  86.  16) CMP2.x  <ea>,Rn
  87.  17) DIVS.l  <ea>,Dq ;DIVS.l  <ea>,Dr:Dq
  88.  18) DIVSL.L <ea>,Dr:Dq
  89.  19) DIVU.l  <ea>,Dq ;DIVU.l  <ea>,Dr:Dq
  90.  20) DIVUL.L <ea>,Dr:Dq
  91.  21) EXTB.L  Dn
  92.  22) LINK.L  An,#<data>
  93.  23) MOVE    CCR,<ea>
  94.  24) MOVEC   Rn,Rc ;MOVEC  Rc,Rn
  95.  25) MOVES.x Rn,<ea> ;MOVES.x  <ea>,Rn
  96.  26) MULS.l  <ea>,Dl ;MULS.l <ea>,Dh:Dl
  97.  27) MULU.l  <ea>,Dl ;MULU.l <ea>,Dh:Dl
  98.  28) PACK    Dn,Dm,#<data> ;PACK  -(An),-(Am),#<data>
  99.  29) RTD     #<data>
  100.  30) TRAPcc ;TRAPcc  #<data>
  101.  31) UNPK    Dn,Dm,#<data> ;UNPK  -(An),-(Am),#<data>
  102.  
  103. Rn=any general register, Dn=any data register, An=any addrress register
  104. Rc=any control register,<ea>=an effective address, #<data>=immediate data
  105.  
  106.  
  107. (!) Bcc.l is emulated only if the branch is taken!
  108.  
  109.  Bra.l,Bcc.l and BSR.l cause  an address  error exception, other instructions
  110. cause illegal instruction exception.
  111.  
  112.  Refer to an  appropriate book  for more  information about these instructions
  113. and addressing modes.
  114. ------------------------------------------------------------------------------
  115.  
  116.  The Story:
  117.  
  118.  I began to  write a software  emulation program  some time ago, after reading
  119. about 68010 in a book.From that  time I have  continued to enhance the program
  120. gradually. This  is the  third public  release of the  program  and is a major
  121. update to the previous version, Run68013. Main changes to the previous version
  122. are:
  123.    More instruction are emulated.
  124.    The emulated instructions can use new 68020 addressing modes. 
  125.    The program supports single stepping.
  126.    A number of  bugs which  I found have been removed and some parts have been
  127.  rewritten or otherwise changed to produce (I hope) better code.
  128.  
  129.  Some may  say that  producing such  programs is  useless, because the  prices
  130. of 32 bit motorola processores are not very high  and most  people can  afford
  131. them. This  is in fact  true, but I  believe  there are  always  people  whith 
  132. restricted budgets. On the other hand  writing a program of  this kind  taught 
  133. me some good  lessens (among  them the  fact that  how hard it is to enhance a
  134. badly written program!). I really hope it will be helpful to some Amiga Users.
  135.  
  136.  To tell the  truth, what  worried me  very much during the time I was writing
  137. Run680XX was to hear that Motorola has ceased production of the 68000!.  
  138.  
  139.  I  completed  writing this version of the program short after I sent Run68013 
  140. to Fred Fish, but  decided not  to release  it publicly until I could test the
  141. program. Unfortunately Commodore  representatives in Iran do not import Amigas
  142. with 32 bit CPUs, so access to these processors is very hard for Amiga users.
  143. On the other  hand Apple  representatives are very active and at the same time
  144. very friendly. I went to one of them and asked if they could help me, and they
  145. could!, so I  took my Amiga there and put it beside a Mac II si. After writing
  146. a short test program, I  started to  execute the same program on both machines
  147. line by line and compare the results obtained from the emulator and the 68030. 
  148. Unfortunately I  had not  enough time, but it was  possible to use some of the 
  149. instructions and see their effects in practice.
  150.  
  151. ------------------------------------------------------------------------------
  152.  
  153. Program Description:
  154.  
  155.  The program does the following when executed the first time:
  156.  
  157.  It tests the EXECBase  structure to see if it reports a 68000 or 68010 CPU,If 
  158. the program does not find  any of them, then it will show a requester and quit 
  159. without doing anything.Memory  is allocated  and emulation routines are copied 
  160. there.After that a window opens showing  some information about the program. 
  161.  A  message  port  is set up to indicate the presence of the program.This will 
  162. help to prevent running muliple copies of the program. 
  163.  Based of  the command line parameters the program may copy the address of the
  164. emulation  routines at  the illegal  instruction  and address  error exception 
  165. vectors and a window may open showing the current active 'processor'.
  166.  
  167.  One  can  install or  remove  the  emulation  routines  by  a  click  in  the 
  168. 'CHANGE CPU' gadget. Quitting the program  when the processor is '68017' ,will 
  169. let the emulation routine to stay in memory.Then only a reset will remove it.
  170. Quitting when the processor is 68000 will remove every thing.
  171.  
  172.  When run from the SHELL, one can enter one of the two arguments, like this:
  173.  
  174. 1> run Run68017 68k
  175.  
  176.   or
  177.  
  178. 1> run Run68017 quit
  179.  
  180. the arguments  are  not case  sensetive. '68k' will  prevent  the program from 
  181. installing the routines and the  processor will remain the  68000. 'quit' will 
  182. instruct  the  program to  install the routine and then quit.After that only a
  183. reset will remove  the installed  routine.Only one of the two arguments can be 
  184. enterd  because  giving  both at the  same  time  is senseless. So the program 
  185. considers the first argument if several are provided on the command line.
  186.  
  187.  When an illegal instruction  or address  error  exception is  encountered the 
  188. routine tries to identify the instruction causing the problem and if it is one 
  189. of the emulated instructions, it is emulated using self modifying  code (Thank
  190. you Von Neumann Architecture! you let code and data be considered the same).
  191. The address of the next instruction is obtained and is used to replace the
  192.  address of the instruction that caused the exception.If the trace bit was set 
  193. before  the  exception  happened, the address of the  trace exception  and the 
  194. status register (with the  supervisor bit set and the trace bit reset) are put
  195. on the  stack, then   an rte is  used  to  transfer  the control to  the trace 
  196. exception handling routine.
  197.  
  198.  As the  emulation  code is not reentrant, multitasking is disabled during the
  199. emulation. 
  200.  
  201.  If non of  the  emulated instructions  are recognized, the program places the 
  202. original exception handler  routine  and  status register (with the supervisor 
  203. bit  set and  the  trace bit reset) on  the stack  then an rte  is executed to 
  204. transfer control to the original exception handler.
  205. ------------------------------------------------------------------------------ 
  206.  
  207. Bugs/Limitations:
  208.  
  209.  Here are the known  limitations/bugs  in the  program and  explanations about 
  210. some of the routines:
  211.  
  212. * Only the emulated instructions can use new 68020 addressing modes.
  213.  
  214. In Bcc.l instruction:
  215. * If the branch is not taken, the 68000  will 'execute' the displacement value
  216.    after the op-code.The results are unpredictable.
  217.  
  218. In MOVEC instrcuction:
  219. * Executing this instruction in user mode causes a privilage violation.
  220.  
  221. * All the 68020 control registers are simulated by memory locations
  222.  
  223. * Both the MSP and ISP are interpreted as SSP.
  224.  
  225. * Before writing something in the  MSP or ISP,make sure at least 12  bytes are
  226.    available below the new  stack value because 12 bytes may be written in the
  227.    new satck pointer before  returning to the main program. 
  228.  
  229. * Writting a value in A7 register won't have any effect.
  230.  
  231. * If a value other than  zero is copied in VBR, 1KByte of  memory  starting at
  232.    the new contents of  the VBR  are copied  to the first  KByte of  memory to 
  233.    ensure the use of proper vectores. 
  234.  
  235. In MOVES.x instruction:
  236. * Executing this instruction in user mode causes a privilage violation. 
  237.  
  238. * No interpretation of the contents of the DFC or SFC are made during the move
  239.  
  240. * Writting a value in A7 register won't have any effect. 
  241.  
  242. The CAS and CAS2 instruction:
  243. *  Are ofcourse not indivisible.
  244.  
  245.  
  246. ------------------------------------------------------------------------------
  247.  
  248. Compatibility:
  249.  
  250.  A software emulater can not make up for the weaknesses in  the hardware (like
  251. a narrower Data/Address  Bus, or the absence of Cache memory).
  252.  
  253.  There is not much more that can be added to an  emulation program  like this, 
  254. which is based on "exception  processing, rather than examining the code to be
  255. emulated  line by line". The advantage is more  speed and the  disadvantage is
  256. that  the emulation won't be %100.
  257.  
  258.  Unfortunately the  old 68000 instructions, when using 68020 addressing modes,
  259. don't cause an exception, so this program can not emulate them.This means that
  260. with a  very high  probability, most  real world  programs needing  an MC68020 
  261. won't be able to run using this emulator.Most compilers  DO  produce code that
  262. use new  addressing  modes. But the interested  user can  use this software to 
  263. enbable him/herself to become  more aquainted  with 68020/030/040 capabilities 
  264. without  investing in an  accelerator  card. This is my main reason of writing 
  265. this code.
  266.  
  267.  Running a program witch uses new addressing modes for older instructions will
  268. cause  unpredictable results, based on  the interpretations of the instruction
  269. extension words by the good old 68000!.Most probably you'll visit MR. GURU!.
  270.  
  271.  Note that using this software  not only  does not bring any speed advantages,
  272. but  depending  on  the  frequency of  encountering  the  instructions  to  be 
  273. emulated, you'll have an speed reduction, though it would be negligible.
  274. ------------------------------------------------------------------------------
  275.  
  276. Bug Reports:
  277.  
  278.  It would  be very  helpful  if I  could receive  bug reports  from  you. When 
  279. encountering a  bug, please write  enough  information  to make it possible to
  280. track the bug. Write what  happened when  you found  the bug ( GURU, HangUp or
  281. what  ever). Among  the  things  that  would  help  in  debugging, beside  the 
  282. instruction  that  cuaed the  problem, are  the CPU registers  just before the 
  283. problem occured and status register contents. 
  284.  
  285.  It  would  be nice  if some  one with  access  to both  a 68000 and 68020 (or  
  286. higher) processors  would take the trouble and write a test program to compare 
  287. the hardware CPU and the emulator.
  288.  
  289. ------------------------------------------------------------------------------
  290.  
  291. Next Version:
  292.  
  293.  Logically the next version of the program  should be a bug-fix, but only if I 
  294. could find out the bugs!.
  295.  
  296.  As you read earlier, not much more can be done about the emulation if we rely
  297. on exception processing only, because there are few other things that cause an 
  298. exception. To overcome this inherent problem I first  thought that it would be
  299. possible to read an executable file, find instructions that use new addressing
  300. modes, change the  relative bits to show an  illegal addressing mode, and then
  301. execute the program. This program  already emulates 68020 addressing modes and
  302. it needs little effort to handle old instructions to use them as well.So we'll 
  303. have a complete 68020 emulator.
  304.  But the  problem is that in this way  one should follow the execution flow as 
  305. the processor  does when  the program is run, this  is because we don't have a
  306. way to find out what is an instruction and what is data  (Damn you Von Neumann
  307. Architecture!).This  would be  a semi 'Compiler' for translating 68020 code to 
  308. 68000.But I think it is not  worth the effort because we are forced to produce
  309. a 68000 emulator  before  proceeding!. Any body  has any suggestions regarding
  310. this approach?.
  311.  
  312.  The other thing we can do is to make an 'Interpreter'.In this way the program
  313. that  containes  68020  specific  instructions/addressing  modes is  loaded in 
  314. memory and the address of its first instruction is obtained. Then it is put in 
  315. single step and we examine  the instruction to be executed  after the previous
  316. one has been executed. If a new addressing  mode is found then it is simulated
  317. and program continues with the next instruction.To do this, I need to know how 
  318. we can  load a  program  to memory, obtain its first  instruction  and set the
  319. single step bit for it, much like the thing that all debuggers do.Please write
  320. to me if you can  help in  this area. I don't have  any access  to information 
  321. about DOS library and other related material like segments, hunks and so on.
  322. ------------------------------------------------------------------------------   
  323.  
  324. Finally:
  325.  
  326.  The code  has been  written and  assembled with  Profimat  (AssemPro), but it
  327. should also do well with  other  assemblers, as few profimat-specific features
  328. have been used.
  329.  
  330.  I have not tested the program under any  other OS  version or CPU. Maybe some
  331. one will do so and kindly let me know about the results.
  332.  
  333.  
  334.   You have lots of options for paying for the program:
  335.  
  336. 1) Explain  how  debuggers work,  that is, how they  load a  program from disk
  337. to memory and place it in single step, allowing it to be executed line by line
  338. also, how we can find out  that the program under debugging has actually ended
  339. (or putting it another way, how to  find out that which rts is the last one in
  340. the program code?). 
  341.  
  342. 2) Send a small donnation. 
  343.  
  344. 3) Send me computer  books (especially  Amiga  books), Software or manuals you 
  345. don't need  any more, or  even  photocopies  of articles in books or magazines
  346. containing Amiga programming guides or examples.
  347.  Here in Iran I have not much  access to  information on  the Amiga so I would
  348. appreciate receiving technical information in any form. 
  349.  
  350. 4) Send me bug reports and mention the weak points of the program and the ways
  351. to improve it.My main reason of writing programs is to learn more.
  352.  
  353.  
  354.  
  355.  
  356.  Send any bugs you find or any suggestions or donnations to
  357.  
  358.                Kamran Karimi
  359.                2,Hassanabad
  360.                Haghshenas  str.
  361.                Navab       str.
  362.                13599 - Tehran
  363.                Iran
  364.  
  365.